Virtual machines, particularly those that attempt to capture an entire machine's state, are increasingly being used as vehicles for deploying software, providing predictability and centralized control. The virtual environment provides isolation from the uncontrolled variability of target machines, particularly from potentially conflicting versions of prerequisite software. Skilled personnel assemble a self-contained software universe (potentially including the operating system) with all of the dependencies of an application, or suite of applications, correctly resolved. They then have confidence that this software will exhibit the same behavior on every machine, since a virtual machine monitor (VMM) will be interposed between it and the real machine.
Virtualization (system and application) technology has been gaining widespread commercial acceptance in recent years. System virtualization allows multiple operating system (OS) stacks to share common hardware resources such as memory and CPU. System virtualization is generally implemented as a mediation layer that operates between the OS and the hardware. Application level virtualization technologies allow multiple application stacks to share a common OS namespace, such as files and registry entries. Application level virtualization is generally implemented as a mediation layer that operates between the application processes and the OS. With system virtualization, an OS stack can be given the illusion that required hardware resources are available, whereas in reality they may be shared by multiple OS stacks. With application virtualization, an application can be given the illusion that its files and registry entries are exactly where it expects them to be on the host machine, whereas in reality multiple application install images may be sharing the same locations in the namespace.
General reference with regard a virtual execution environment (one known as a Progressive Deployment System (PDS)) may be made to VEE '05, Jun. 11-12, 2005, Chicago, Ill., USA, “PDS: A Virtual Execution Environment for Software Deployment”, Bowen Alpern, Joshua Aurbach, Vasanth Bala, Thomas Frauenhofer, Todd Mummert, Michael Pigott.
The two types of virtualization technology (i.e., system and application) operate at different levels of the stack, and their value propositions are complimentary. System virtualization enables encapsulation of the state of a complete OS and applications software stack within a virtual system container, while application virtualization enables encapsulation of the state of an application stack only within a virtual application container. Both types of virtualization allow their respective containers to be deployed and managed as an appliance, i.e., as a pre-installed and pre-tested environment within a secure region that is isolated from other stacks that share the same environment. This has significant commercial value from an IT management standpoint, since appliances provide greater robustness and security assurances than conventional install-based methods of deployment.
Virtual application containers can be delivered as a stream (over a network from a server to the host) as the application executes. Streaming is the overlap of delivery of a virtualized application (and its container) with the execution of the application (in its container). Streaming is accomplished by decomposing an application (and its container) into components. Components are brought to the host machine on demand (as they are required) or they are prefetched (before they are required). Prefetching reduces the application latency due to the transfer of components from a server to the host.
To be effective prefetching should accomplish at least three goals. First, it should identify good candidate components for transfer. Second, it should provide an estimate of the urgency of such a transfer. And, third, it should not consume excessive system resources (such as bandwidth between the server and host, space on the host, CPU cycles on the host, bandwidth between the host and a local disk, as non-limiting examples).
In general prefetching uses a model that encodes patterns of component utilization that are derived from observations of independent application behaviors. However, such observations are difficult to obtain and must themselves be treated as scarce resources.
Software execution typically requires components in bursts: i.e., a sequence of components that are all required (in order) in a short time span. One simplistic approach to prefetching would be to identify such bursts and bundle them into a single package. As soon as the first component is required, the entire package (all components of the burst) is transferred. This allows the transfer of all but the first component of the burst to be overlapped with the execution that is enabled by the arrival of the first component until the point that the last component is required. However, one drawback of this approach is that first component is fetched on demand, with the application waiting idly until the first component arrives. Another drawback is that the time required to transfer the remaining data in the burst may far exceed the execution time of the burst.
A more effective approach would attempt to prefetch (at least) a prefix of a burst before its first component is required. An advantage in this approach is that there is much more time between bursts than there is within them. One difficulty associated with this approach is that it is much harder to predict the order of bursts that it is to predict their contents. Thus, the use of this approach to prefetching can result in transferring the prefixes of many bursts before it is apparent which burst will occur next. This could obviously consume system bandwidth and resources needlessly.
Another consideration to be kept in mind with respect to prefetching is its impact on the performance of the virtualized execution. The two processes often compete for scarce system resources. This competition can be direct as when the application needs to share the channel connecting the client to the server, or to use another channel that shares some underlying resource, or to use another system resource, such as a disk, that may also involved in the prefetching operation.
Reference can be had to U.S. Pat. No. 7,062,567, Intelligent Network Streaming and Execution System for Conventionally Coded Applications. As is stated in col. 21, lines 29-48:
“Static and Dynamic Profiling—With respect to FIG. 21, since the same application code is executed in conjunction with a particular Stream Application Set 2103 each time, there will be a high degree of temporal locality of referenced Application File Pages, e.g., when a certain feature is invoked, most if not all the same code and data is referenced each time to perform the operation. These access patterns can be collected into profiles 2108, which can be shipped to the client 2106 to guide its prefetching (or to guide server-based 2105 prefetching), and they can be used to pre-package groups of Application File Pages 2103, 2104 together and compress them offline as part of a post-processing step 2101, 2102, 2103. The benefit of the latter is that a high compression ratio can be obtained to reduce client latency without the cost of runtime server processing load (though only limited groups of Application File Pages will be available, so requests which don't match the profile would get a superset of their request in terms of the pre-compressed groups of Application File Pages that are available).”
However, no details are provided as to how “access patterns can be collected into profiles”.
U.S. Pat. No. 7,062,567 discusses the idea of applying predictive caching techniques, such as those that have been discussed in the context of distributed file systems, to the context of streaming software. Evident disadvantages of this approach include, but are not limited to: it can only exploit very high frequency temporal locality (correlations between different “features” are ignored), candidates for prefetching are not graded for urgency (all candidates are equally urgent), and the prefetch algorithm apparently does not consider contention for scarce system resources.